Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

Using the SchemaLocation attribute

Change this attribute for performance reasons only very rarely, especially for dynamic SDOs. The entity cache exists to improve performance for all objects that need schema information at run time, both visual objects and data objects, but the actual caching has to happen somewhere. Setting SchemaLocation to ENT adds overhead to the SDO startup the first time it is started if the particular entities are not already cached. However, changing the SDO to not use the entity cache, in most cases, moves the responsibility and overhead to some other object. Also note that entities, in most cases, are already cached, either at startup or by startup of another object.

Factors to consider before changing this setting include:

SDOs that do not use any visual objects and that access entities not used by other objects can get a performance benefit from using the DLP setting, because these particular entities do not need to be cached.
SDOs that do not use the ENT setting can be used without importing entities into the Repository.
The BUF setting is currently 50% to 70% slower than the two other settings.
SDOs that have OpenOnInit set to TRUE define the temp-table on the first request to the server; SDOs that have OpenOnInit set to FALSE need to define the temp-table on the client, and thus require the cache to be on the client. You cannot use the BUF setting on SDOs with OpenOnInit set to FALSE.
The DLP setting is static in the sense that the information is not any fresher than the last compilation of the DataLogic procedure.
Note: Static SDOs derive a performance benefit from not using the ENT setting, because the Entity definition must be added in an additional loop. The DLP setting is currently ignored for static SDOs, because both BUF and DLP make the SDO use the definitions already compiled into them.